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^ (57) Abstract: The invention relates to a rapid method of loading an application that is to deployed (AP) in a terminal (2) and a chip 
card (3) from a server (1). According to the invention, a message (MAP), containing a first application part and a second application 
part which is formatted to be compatible with a communication protocol between the terminal and the card, is transmitted by the 
^ server to the terminal which stores said two parts. The first part (APT) extracted from the application message (MAP) is installed 
S in the terminal. A specific loader (CAPC) loads the second part (APC) extracted from the message according to the communication 
^ protocol. The installation of the two application parts are synchronised under the control of the terminal. 

^ (57) Abrege : Pour charger rapidement depuis un serveur (1) une application a deployer (AP) dans un terminal (2) et une carte a 
puce (3), un message (MAP) contenant a la fois une premiere partie d'application et une deuxieme partie duplication formatee pour 
Q etre compatible avec un protocole de communication entre le terminal et la carte est transmis par le serveur au terminal qui memorise 
^ les deux parties. La premiere partie (APT) extraite du message 
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d'application (MAP) est installed dans le terminal. Un chargeur specifique (CAPC) charge la deuxieme partie (APC) extraite du mes- 
sage selon le protocole de communication. Les installations des deux parties d'application sont ainsi synchrones sous la commande 
du terminal. 
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Chargement d'une application a deployex dans tin 
terminal et une carte a puce 

La presente invention concerne le chargement 
5 d'une application a deployer, dite egalement 
application a distribuer, dans un terminal et une 
carte a puce, ^ite egalement carte a microcontrdleur 
ou carte a circuit int6gr<§. 

Le terminal accueille la carte a puce et peut 
10 Stre selon un exemple prefer^ un terminal 
radiotelephonique mobile pour lequel la carte a puce 
est un module d'identite d'usager amovible SIM 
(Subscriber Identity Module), auquel on se referera 
dans la suite de la description. Selon d'autres 
15 exemples, le terminal peut etre un terminal bancaire 
accueillant une carte de debit ou de credit, ou un 
ordinateur personnel (PC) dot6 d'un lecteur de carte 
a puce, ou bien un petit equipement communiquant tel 
qu'un assistant numSrique personnel (PDA) pouvant 
20 lire une carte a puce introduite dans celui-ci. 

L 1 invention concerne ainsi d'une maniere 
gSnSrale un terminal ouvert dans lequel est 
• implements un systeme d T exploitation ouvert qui 
autorise un telSchargement dynamique d' applications 
25 additionnelles "au-dessus" du systeme d 1 exploitation 
partiellement dans une carte a puce accueillie dans 
le terminal. 

En se rSferant a la figure 1, on a represents 
30 les principales entites pour tSlecharger une 
application composee d'une premiere partie PAl et 
d'une deuxiSme partie PA2 depuis une plate-forme OTA 
(Over The Air) telle qu'un serveur d' application SAP 
vers un terminal radiotelephonique mobile TE 
35 contenant une carte a puce amovible CP du type carte 
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SIM. Le terminal TE ainsi que la carte & puce CP 
contiennent chacun un interpreteur du type machine 
virtuelle Java ou Microsoft (marques enregistrees) . 
En particulier, le terminal inclut un gestionnaire de 
5 carte G pour gerer les echanges de donnees entre le 
monde ext6rieur au terminal TE et la carte A puce CP. 

Le serveyr d r application SAP est ger6 par 
exemple par un fournisseur d' application pour 
terminaux mobiles et op6re de la maniere suivante 
10 pour t616charger une application composee des parties 
PA1 et PA2 . 

La premiere partie PA1 destin6e k etre chargee 
dans le terminal TE est telechargee & travers un 
r£seau de paquets du type internet RP, un reseau 

15 telephonique commute RTC et le reseau de 
radiot616phonie RR auquel appartient le terminal TE, 
Le telechargement de la premiere partie d' application 
PA1 est effectuee avec un- debit 61ev6, typiquement de 
9600 bits/s, notamment & travers un canal de trafic 

20 du reseau de radiot61-6phonie RR. La partie PA1 est 
installee et g6ree par un gestionnaire d' application 
G implements dans le terminal. 
^ * La deuxieme partie d 1 application PA2 destin6e a 

la carte £ puce CP ne peut etre t616charg6e que par 

25 1 1 interm6diaire de messages courts MC dont le debit 
est faible, de quelques centaines de bits par 
seconde, et done tr6s inf6rieur au debit pour 
tel6charger la premiere partie d ! application PA1. 
Ainsi, la deuxieme partie d' application PA2 transite 

30 a travers le rdseau de paquets RP, un serveur de 
messages courts SMC generant g6n6ralement plusieurs 
messages courts MC segmentant la partie d ? application 
PA2 transmis directement ou k travers un reseau 
interm£diaire RI du type RNIS ou X.25 vers le rSseau 
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de radiotelephonie RR, puis £l travers le terminal TE 
qui est transparent a la partie d 1 application PA2. 

La separation de 1 1 application en deux parties 
PA1 et* PA2 a travers des chemins de transmission 
5 diff6rents RP-RTC-RR et RP-SMC-RI-RR entraine 
naturelleraent une desynchronisation des parties 
d ■ application _,ef f ectivement telechargees s£par§ment 
dans le terminal TE et la carte & puce CP. Puisque 
les telechargements sont effectues separement, le 

10 terminal TE et la carte a puce CP accusent reception 
d'une maniere s6par6e et non simultanfee du 
t£lechargement des parties PA1 et PA2 au serveur SAP 
avant de commencer toute execution de 1 1 application 
[PA1, PA2] dans l 1 ensemble terminal TE et carte a 

15 puce CP. En particulier, le gestionnaire 
d' application G doit attendre que la deuxieme partie 
d» application PA2 soit corapletement teltchargee audit 
debit faible dans la carte CP pour decider d'une 
execution de 1 'application. 

20 

L 1 invention a pour principal objectif de 
rem6dier aux inconv6nients dus a la desynchronisation 
des chargements des deux parties d 1 application selon 
la technique ant£rieure. Elle vise plus 

25 particulierement a fournir un mecanisme de 
synchronisation au terminal pour qu'il charge lui- 
meme la deuxifeme partie de 1 1 application distribute 
tout en ayant regu rapidement les deux parties de 
1 '.application avec un debit nettement plus 61eve que 

30 celui offert par une transmission de messages courts. 
Si ntcessaire le terminal ne transmet qu'un seul 
message d' acquittement apr6s 1 1 installation de 
1 1 application dans le terminal et la carte a puce. 
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Pour atteindre cet object if, un precede pour 
charger depuis un serveur une application incluant 
une premiere partie destinee a un terminal dote d'un 
moyen gestionnaire d f application et une deuxieme 
5 partie destinee k une carte k puce accueillie dans le 
terminal , est caract6ris6 en ce qu'il comprend les 
etapes de : ^ 

- fournir au terminal un moyen de chargement 
pour charger la deuxieme partie d' application dans la 

10 carte k puce, 

- formater dans le serveur la deuxieme partie 
d 1 application pour qu'elle soit compatible avec un 
protocole de communication entre le terminal et la 
carte £ puce, 

15 - construire dans le serveur un message 

d T application contenant la premiere partie 
d 1 application et la deuxieme partie d f application 
formatee, 

- transmettre le message d 1 application depuis le 
20 serveur vers le terminal & travers un unique canal de 

t ransmiss ion r 

- installer dans le terminal la premiere partie 
d 1 application extraite du message d' application par 
le moyen gestionnaire, et 

25 - charger la deuxieme partie d 1 application 

extraite du message d' application depuis le terminal 
dans la carte a puce selon le protocole de 
communication predetermine sous la commande du moyen 
de chargement . 

30 L T invention s'affranchit ainsi du probleme de 

d6synchronisation des chargements d^s premiere et 
deuxidme parties de 1 1 application puisque toutes les 
deux sont installees respectivement dans le terminal 
et la carte a puce sous la commande du moyen 

35 gestionnaire d f application et du moyen de chargement 
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impl6ment6s dans le terminal. Aucun moyen 
supplementaire pour gerer la transmission simultanee 
des deux parties d' application dans un message 
d 1 application commun n'est necessaire dans le 
5 serveur. On unique acquittement peut etre transmis 
par le terminal au serveur pour signaler la 
disponibilit6 ..de 1 1 application ins.jtallee dans le 
terminal pour §tre executee. 

Le moyen gestionnaire analyse un descripteur de 

10 1' application qui a au moins un identif icateur de la 
deuxi&me partie d 1 application formatee et qui est 
contenu dans le message d 1 application construit dans 
le serveur. Le moyen gestionnaire analyse alors le 
descripteur dans le message d 1 application regu par le 

15 terminal afin que la deuxi&ne partie d' application 
soit extraite du message d 1 application en fonction de 
1 1 identif icateur dans le descripteur analyse. Le 
moyen chargeur est ensuite active par le moyen 
gestionnaire pour charger la deuxiSme partie 

20 d r application dans la carte. Le terminal gere ainsi 
lui-meme le chargement de la deuxifeme partie 
d 1 application dans la carte en synchronisme avec 
l 1 installation de la premiere partie d f application 
dans le terminal. 

25 Le telechargement de 1 1 application vers le 

terminal utilise selon l f invention un chemin de 
transmission existant quel que soit le type de 
terminal qui peut §tre un terminal radiot616phonique 
mobile, un terminal bancaire, un ordinateur 

30 personnel, etc. En particulier, lorsque le terminal 
est un terminal radiot§16phonique mobile, toute 
1 1 application est transmise ct travers un canal de 
trafic de 1' interface radio entre le terminal et une 
station de base du reseau de radiot61ephonie, c ! est- 
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A-dire avec un debit nettement plus eieve qu'au moyen 
de messages courts selon la technique anterieure. 

D'autres caracteristiques et avantages de la 
5 pr6sente invention apparaitront plus clairement a la 
lecture de la description suivante de plusieurs 
realisations pareferees de 1' invention en reference 
aux dessins annexes correspondants dans lesquels : 

- la figure 1 est un bloc-diagramme sch^matique 
10 entre un serveur d 1 application et un terminal avec 

une carte £ puce selon la technique anterieure deja 
comment ee ; 

- la figure 2 est un bloc-diagramme schematique 
d'un systeme de telecommunications entre un serveur 

15 d' application et un terminal avec une carte a puce 
selon la realisation pref6ree de 1' invention dans 
laquelle le terminal est un terminal 
radioteiephonique mobile ; 

- la figure 3 est un graphe montrant la 
20 composition d'un message d 1 application transmis par 

le serveur au terminal r selon 1' invention ; et 

- la figure 4 est un algorithme du precede de 
^ ' chargement d' application a deux parties selon 

l 1 invention. 

25 

La realisation pr6feree de 1' invention decrite 
ci-apres en reference a la figure 2 concerne & titre 
d f exemple le chargement d'une application depuis un 
serveur d' application 1 dans un terminal 2 .du type 
30 terminal radioteiephonique mobile dote d'une carte £ 
puce 3 . 

Dans les trois entites 1, 2 et 3 sont 
repr6sentes a la figure- 2 des blocs fonctionnels 
assurant des fonctions ayant un lien avec 1 1 invention 
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et pouvant correspondre £ des modules logiciels et/ou 
materiels . 

Le terminal 2 est inclus dans un reseau de 
5 radiotelEphonie cellulaire numerique RR par exemple 
du type GSM ou UMTS. Plus prEcisEment, le terminal 2 
est relie au^, serveur 1 a travers un reseau de 
telecommunications comprenant classiquement un rEseau 
de paquets RP tel que le rEseau internet , un reseau 

10 telephonique commut6 RTC et le reseau de 
radiotelephonie RR. La carte a puce 3 const itue un 
module d 1 identity amovible du terminal 2 connu sous 
1' appellation "carte SIM" (Subscriber Identity 
Module) . En variante, la carte k puce 3 peut etre une 

15 carte k puce additionnelle k la carte SIM. 

Selon d'autres variantes, le terminal peut etre 
un ordinateur electronique personnel (PC) , ou un 
terminal bancaire, ou un terminal point de vente, ou 
un assistant numerique personnel (PDA), ou un 

20 dispositif portable de transmission de messages, etc. 
En association avec ces divers types de terminal, la 
carte a puce 3 peut §tre un objet electronique 
portable tel qu'une carte de debit ou credit, un 
porte-monnaie Electronique, une carte k puce 

25 additionnelle ou tout autre dispositif Electronique 
petit ou miniature. 

En general, le terminal 2 contient en tant que 
pEriphErique un lecteur 20 dans lequel la carte a 
puce 3 avec ou sans contact electrique est ins6r6e au 

30 mo ins partiellement . 

Le serveur d 1 application 1 const itue un site 
internet appartenant par exemple & 1 ' Editeur de la 
carte k puce 3 ou bien k un Editeur qui Edite des 
35 applications a telecharger dans des cartes a puce. 
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Un programme source PS correspondant a une 
application AP dont une premiere partie APT qui peut 
etre vide est £ telecharger dans le terminal 2 et 
dont une deuxieme partie APC est a telecharger dans 
5 la carte a puce. 3 a ete §crit initialement dans un 
langage de haut niveau du type orients objet tel que 
le langage Javjt. Comme on le verra dans la suite, le 
terminal 2 et la carte k puce 3 contiennent 
respectivement des moyens d 1 execution virtuels tels 

10 qu'une machine virtuelle Java (marque enregistree) 
JVMT pour executer la partie d ? application APT et une 
machine virtuelle Java Card (marque enregistree) JVMC 
pour executer la partie d T application APC. D'une 
maniere connue, le programme source PS est convert i 

15 dans un convertisseur 11 du serveur 1 en un langage 
intermediaire f appeie egalement pseudo-code, compost 
de mots d 1 instructions forme par . des octets appelds 
bytecodes, qui sont prets a etre executes par les 
machines virtuelles JVMT et JVMC imp lament ees dans le 

20 terminal 2 et la carte & puce 3. Le programme compile 
PGC produit par le convertisseur 11 contient la 
premiere partie d ! application APT compil6e et la 
deuxi£me partie d 1 application APC compilee qui 
correspondent & celles contenues dans le programme 

25 source PS et fournies par : un developpeur de I'editeur 
d' application. 

En variante, le convertisseur 11 est impiemente 
& 1 ' exterieur du serveur 1. 

Chaque partie d ? application APT (.class) et APC 

30 (.cap) regroupe un ensemble de composants constituant 
des fichiers pouvant correspondre chacun a une classe 
d f objet, une methode, un repertoire, un en-tete, un 
descripteur, etc. 

En particulier, coranie montre & la figure 3, la 

35 deuxieme partie d ' application APC dedi6e a la carte a 
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puce 3 est segmentee en des commandes EV1 a EVN du 
type "ENVELOPE" qui sont concatenees et qui 
contiennent des donates relatives a la deuxieme 
partie d 1 application APC et directement chargeables 
5 dans la carte a .puce 3. Les commandes EV1 k EVN sont 
compatibles avec un protocole de communication entre 
le terminal 2^.et la carte a puce 3, typiquement un 
protocole asynchrone a l'alternat, et sont propres k 
transferer les donnees de la deuxieme partie 

10 d 1 application APC du terminal 2 a la carte a puce 3 
sans que le terminal 2 les interprete. Les donnees 
dans les commandes EV1 a EVN sont done directement 
interpr£tables par la machine virtuelle JVMC 
implement ee dans la carte a puce 3, de mani^re 

15 analogue a un message court regu par un terminal 
selon la technique anterieure et transme'ttant 
directement k la carte k puce une commande "ENVELOPE 
(SMS-PP DOWNLOAD) " . 

Dans le serveur 1, un format eur 12 formate la 

20 deuxieme partie d' application APC en une succession 
de commandes "ENVELOPE" EV1 a EVN. 

Le serveur d' application 1 comprend egalement un 
constructeur de messages d 1 application 13 et un 
chargeur 14. Le constructeur 13 construit un message 

25 d f application MAP comme montr6 £ la figure 3- Le 
message MAP comprend un en-tete EN, un descripteur 
d f application DAP, la premiere partie d' application 
APT et la deuxieme partie d ' application APC avec les 
commandes concatenees EVl a EVN. Le descripteur DAP 

30 contient en particulier un identif icateur IAPC 
indiquant la position du debut de la deuxieme partie 
d' application APC dans le champ de donnees du message 
MAP succedant au descripteur DAP . L 1 identif icateur 
IAPC servira a extraire la deuxieme partie 

35 d 1 application APC du message MAP memorise dans le 
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terminal 2. Le descripteur DAP constitue un fichier 
JAD (Java Application Descriptor) et 1 1 ensemble des 
donnees [DAP(IAPC), APT, APC] constitue un fichier 
JAR (Java Application Repository) selon la 
5 description de la machine virtuelle Java Card. Le 
message MAP ainsi produit par* le constructeur 13 
contient ainsi^une applet a transmettre au terminal 2 
sous la commande- du chargeur 14 £ travers le reseau 
de telecommunications RT. Le chargeur 14 adapte le 
10 message MAP aux protocoles de transport tel que HTTP 
(HyperText Transfer Protocol) et de r6seau (Internet 
Protocol) du reseau de paquets RP auquel est connect^ 
le serveur 1. 

15 Le terminal 2 du type radiotelephonique mobile 

comprend classiquement , outre le lecteur de carte k 
puce 20 , un processeur 21, des memoires 22 et une 
interface radio 23 reliee par un bus 24 . Les memoires 
22 regroupent di verses memoires telles qu'une memoire 

20 morte, une memoire non volatile EE PROM et une memoire 
RAM. Lorsque le terminal est par exemple un 
ordinateur personnel, les memoires 22 comprennent un 
disque dur. Naturellement, le terminal 2 comprend 
d'autres p^ripheriques & l f interface homme-machine 

25 avec le processeur 22 tels qu'un clavier, un 
afficheur graphique, au moins un haut-parleur, un 
microphone, etc. L' interface 23 transpose en 
frequence, convertit num^riquement , d&nodule et 
decode des messages regus via le reseau fixe dans le 

30 reseau RR. 

Les memoires 22 dans le terminal 2 contiennent 
notamment un syst£me d ? exploitation, la machine 
virtuelle Java JVMT, un navigateur, et di verses 
applications et donn§es. 
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En particulier, dans la memoire non volatile des 
m&noires 22 du terminal 2 est implement' un 
gestionnaire d' installation d' application GIA 
programme en langage Java et executable dans* le 
5 terminal 2. Le gestionnaire GIA sert k installer 
diverses applications dans les memoires 22 du 
terminal et Jl lancer leurs executions, et en 
particulier £ installer et lancer la premiere partie 
APT d'une application d£ployee AP selon 1' invention. 

10 Le gestionnaire GIA peut etre inclus dans la machine 
virtuelle JVMT. 

Le gestionnaire GIA distingue dans un message 
d' application regu MAP la premiere partie 
d' application APT destin'e au terminal 2 par rapport 

15 a la deuxieme partie d' application APC destinee k la 
carte £ puce 3 sans n6cessiter une interpretation des 
donn'es contenues dans les commandes EV1 k EVN par la 
machine virtuelle JVMT. 

En liaison avec le gestionnaire GIA, un chargeur 

20 CAPC pour charger la deuxieme partie d 1 application 
APC depuis le terminal dans la carte k puce est 
impl6mente, selon l 1 invention, egalement sous forme 
de module logiciel dans les m6moires 22 du terminal 
2. Le chargeur CAPC cr6e un lien entre la machine 

25 virtuelle JVMT et le gestionnaire GIA implement's 
dans le terminal 2 et la machine virtuelle JVMC et un 
outil d f installation d 1 application OI implement's 
dans la carte a puce 3 a travers le protocole de 
communication predetermine ayant des unites de 

30 donn'es de protocole (PDU) const itu'es par des 
commandes EV1 a EVN et leurs r'ponses RES1 k RESN 
echangees entre le terminal 2 et la carte k puce 3. 

La carte k puce 3 qui est une carte amovible SIM 
selon la realisation preferee comprend classiquement 

35 sous forme integr'e un microprocesseur 31, une 
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memoire non reinscriptible 32 du type ROM, une 
memoire non volatile 33 du type EE PROM et une memoire 
34 du type RAM destinee essentiellement a echanger 
des donnees avec le terminal 2 a travers un port 
5 d' entree/sortie 35. Les memoires 32 et 33 contiennent 
les codes et les donnees d'un systeme d' exploitation 
OSC et de la ^machine virtuelle JVMC conf orme & la 
specification Java Card. La memoire non volatile 33 
contient diverses applications et est destinee a 

10 recevoir la deuxieme .partie d 1 application APC 
contenue dans un message d T application MAP transmis 
par le serveur 1 & travers le terminal 2 et 
t616charg£e par le lecteur 20 a travers le port 35 et 
la memoire RAM 34. La memoire 33 contient egalement 

15 I'outil d ! installation 01 pour -installer des 
deuxiemes parties d? application APC selon 
1 1 invention. 

En se referant maintenant & la figure 4, le 
20 procede de chargement d'une application AP comprenant 
une premiere partie APT destinee au terminal 2 et une 
deuxieme partie APC destinee & la- carte a puce 3 
♦ comprend essentiellement des stapes SI a S5 executees 
dans le serveur 1 et des etapes Tl a T8 executees 
25 principalement dans le terminal 2. 

On suppose qu'& une etape initiale E0 precedent 
au moins les etapes Tl & T8, le chargeur de deuxidme 
partie d 1 application CAPC selon 1 1 invention a ete 
installe sous la forme d'un module logiciel dans les 
30 memoires 22 par exemple depuis un serveur autre que 
le serveur 1. 

A l 1 etape SI, un d6veloppeur de l'fediteur 
d f application gerant le serveur 1 6crit 1 1 application 
AP en langage source de haut niveau de mani^re a ce 
35 qu'elle contienne deux parties APT et APC en langages 
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Java et Java Card respectivement destinies au 
terminal 2 et a la carte a puce 3. Le- convertisseur 
11 convertit 1 1 application AP = [APT, APC] en un 
programme compile PGC[API, APC] en langage 
5 intermediaire (pseudo-code) . En variante, les etapes- 
SI et S2 sont realisees a I'exterieur du serveur 1 et 
le programme compile PGC est charge dans le serveur. 

Puis les etapes S3, S4 et S5 sont respectivement 
effectuees par le formateur 12, le constructeur 13 et 

10 le chargeur 14. A l»§tape S3, le formateur 12 formate 
les parties d 1 application compilees APT et APC pour 
qu^lles soient respectivement compatibles avec le 
gestionnaire d' installation GIA dans le terminal 2 et 
l'outil d' installation 01 dans la carte a puce 3. En 

15 particulier, la deuxieme partie d f application APC est 
segmentde en des unites de donnees de protocole EV1 a 
EVN, comme montr6 a la figure 3, qui sont conformes 
au protocole de communication entre le terminal 2 et 
la carte & puce 3 au niveau de la liaison entre le 

20 lecteur 20 et le port d f entree/sortie 35. 
Typiquement, les commandes EV1 k EVN incluses dans la 
partie APC sont formatees comme des messages courts 
• selon la norme GSM. A l'6tape S4, le constructeur 13 
ajoute un en-tete de message EN, un descripteur 

25 d* application DAP contenant au moins 1 1 identif icateur 
de deuxieme partie d' application IAPC et prec6dant 
les parties d' application APT et APC concatenees. Le 
message ainsi construit MAP contient un fichier du 
type JAR incluant les champs DAP, APT et APC. 

30 Puis k l'6tape S5 le chargeur 14 transmet le 

message d 1 application construit MAP vers le terminal 
2 a travers le r6seau de t61ecommunications RT, 
c'est-a-dire £ travers un unique canal de 
transmission, et non s6parement en deux parties £ 

35 travers deux chemins de transmission distincts et 
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desynchronisees RP-RTC-RR et RP-SMC-RI-RR selon la 
technique anterieure montree a la figure 1. 

A la reception du message MAP dans le terminal 
5 2, le processeui: 22 commande l'ecriture des donnees 
DAP, APT et APC contenues dans le message MAP dans la 
memoir e RAM de& memoires 22 , a l'etape Tl. 

A l'etape T2, le descripteur DAP extrait du 
message regu MAP et memorise dans les memoires 22 est 

10 analyst notamment par le gestionnaire d' installation 
d' application GIA qui est* lance. Grace a 1 f analyse .du 
descripteur DAP sont> reper^es les parties 
d 1 application APT et APC dans le champ de donnees du 
message MAP. Tout d'abord a l'6tape T3 r le 

15 gestionnaire d 1 installation GIA via le processeur 21 
lit la premiere partie d 1 application APT et 1 T extrait 
du message MAP dans les memoires 22 pour 1' installer 
particuli^rement dans la m6moire non volatile de 
celles-ci. La partie APT ainsi installee pourra etre 

20 executee par la machine virtuelle JVMT aprds le 
chargement de la deuxieme partie APC dans la carte a 
puce 3. Naturellement f si la partie APT est vide, 
*l T 6tape T3 n'est pas ex6cutee. 

Le gestionnaire GIA active le chargeur CAPC qui 

25 extrait la deuxieme partie d f application APC du 
message MAP ecrit dans les memoires 22, & l f 6tape T4, 
en ignorant le contenu de la partie APC et 
particulierement le contenu des unites de donnees de 
protocole EV1 & EVN. Le chargeur CAPC repere la 

30 partie APC dans le message MAP au moyen de 
1' identificateur IAPC :lu . dans le descripteur 
d 1 application DAP analyse a l'etape T2. La partie APC 
a ete correctement format^e par le formateur 12 pour 
etre directement exploitee dans la carte a puce 3. 
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' Puis le chargeur CAPC initie un echange avec la 
carte a puce 3 pour charger la deuxieme partie 
d* application extraite APC depuis les memoires 22 a 
travers le lecteur 20 et le port d 1 entree/sortie 35 
5 dans la memoire. RAM 34 de la carte a puce 3. La 
deuxieme partie d 1 application APC est segmentee en 
des commandes^EVl a EVN de maniere a les charger 
successivement dans la carte a puce 3, a l'etape T5. 
Pour chaque commande "ENVELOPE" EVn transmise par le 

10 lecteur 20, avec 1 n N, le processeur 31 dans la 
carte £ puce 3 en liaison avec l'outil d 1 installation 
01 retourne une reponse respective REPn selon le 
protocole predetermine d ! 6change de commande et de 
reponse entre le lecteur 2 et la carte k puce 3. La 

15 reponse REPn est analysdse par le chargeur CAPC. Si la 
reponse REPn contient un acquittement positif, le 
chargeur CAPC continue le processus de chargement de 
la deuxieme partie d' application APC en transmettant 
la commande suivante EV(n + 1) suivante, et ainsi de 

20 suite. Dans le cas contraire, la reponse REPn 
contient une erreur que le chargeur CAPC signale au 
gestionnaire d 1 installation GIA qui la retransmet 
•sous la forme d'un message d 1 erreur au serveur 
d 1 application 1. Le chargement de la deuxieme partie 

25 d' application au fur et a mesure de la transmission 
des commande s EV1 a EVN est completement transparent 
dans le terminal 2, c f est-a-dire n'engendre aucun 
affichage de message correspondant ou de message 
d'attente dans le terminal 2. Au fur et k mesure de 

30 la transmission des commandea EV1 a EVN, l'outil 
d 1 installation 01 installe progressivement la 
deuxieme partie d f application APC dans la carte a 
puce 3 en trans f£rant les enveloppes EV1 a EVN de la 
memoire RAM 34 a la memoire EEPROM 33, k l'6tape T6. 
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De preference, apr6s reception de la demiere 
reponse REPN de la carte a puce 3 a la dernidre 
commande EVN, le chargeur CAPC efface la deuxieme 
partie d 1 application APC regue avec le message MAP 

5 dans les memoires 22 . & I'etape T7 . Puis le 
gestionnaire d 1 installation d f application GIA 
commande dans^. le terminal 2 la transmission d'un 
message d 1 acquittement ACK au serveur 1 via le reseau 
RT des que le chargeur CAPC a termine le chargement 

0 de la deuxi&me partie d T application APC dans la carte 
a puce 3, c'est-£-dire apres les etapes T5 et T6 et 
optionnellement I'etape T7 . 



En variante, au lieu que le chargeur de deuxieme 

15 partie d' application CAPC- soit installe prealablement 
sous la forme d'un module : logiciel dans le terminal 2 
par d'autres moyens electroniques que le serveur 
d' application 1, le module- logiciel incluant le 
chargeur CAPC est prealablement introduit dans le 

20 message MAP par le constructeur 13 sous la forme d'un 
script SC, comme indiqu6 entre parentheses dans un 
champ du message MAP dans la figure 3 et a I'etape S4 
.dans la figure 4. Au cours de I'etape S4 de 
construction du message MAP, le constructeur 13 

25 ajoute le script SC apres le descripteur DAP qui est 
modifie en consequence. A I'etape T2 r le gestionnaire 
GIA extrait le script SC dans le message 
d 1 application MAP regu par le terminal 2 de maniere a 
installer le script SC dans la memoire non volatile 

30 des memoires 22. Le script SC est ensuite lance par 
le gestionnaire GIA pour notamment extraire la 
deuxieme partie d r application APC et la charger dans 
la carte a puce 3 aux etapes T4 et T5. 

Selon une autre variante, le message 

35 d' application MAP ne contient pas le script SC. Une 
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aciresse de script URL (Dniform Resource Locator) 
designant un emplacement dans un serveur ayant stocke 
le script SC est introduite au cours de la 
construction S4 du message d 1 application MAP a 
5 transmettre au , terminal 2. A l'etape T2, le 
gestionnaire GIA dans le terminal 2 extrait l'adresse 
de script du message regu et memorise MAP et requiert 
aupres du serveur design^ par l'adresse extraite le 
telechargement du script SC dans les memoires 22 du 
10 terminal 2 . Le script SC est ensuite lance par le 
gestionnaire GIA pour notarament extraire la deuxieme 
partie d r application APC et la charger dans la carte 
£ puce 3 aux 6tapes T4 et T5. 
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REVEND I CAT IONS 

1 - Procede pour charger depuis un serveur (1) 
une application (AP) incluant une premiere partie 

5 (APT) destinee a un terminal (2) dote d f un moyen 
gestionnaire d r application (GIA) et une deuxieme 
partie (APC) ^ destinee a une carte a puce (3) 
accueillie dans le terminal, ca£acteris6 en ce qu'il 
comprend les 6tapes de : 
10 - fournir (E0) au terminal (2) un moyen de 

chargement (CAPC) pour pharger la deuxieme partie 
d' application dans la carte & puce (3) , 

- formater (S3) dans le serveur (1) la deuxieme 
partie d Y application (APC) pour qu'elle soit 

15 compatible avec un protocole de communication entre 
le terminal (2) et la carte & puce (3), 

- construire (S4) dans le serveur (1) un message 
d' application contenant la premiere partie 
d' application (APT) et la deuxidme partie 

20 d 1 application formatee (APC) , 

transmettre . (S5) le message d' application 
(MAP) depuis le serveur (1) vers le terminal (2) & 
. travers un unique canal de transmission (RT) , 

- installer (T3) dans le terminal (2) la 
25 premiere partie d f application (APT) extraite du 

message d T application (MAP) par le moyen 
gestionnaire, et 

charger (T4-T5-T6) la deuxieme partie 
d ? application (APC) extraite du message d' application 
30 depuis le terminal (2) dans la carte & puce (3) selon 
le protocole de communication predetermine sous la 
coramande du moyen de chargement (CAPC) . 

2 - Proc6d6 conforme a la revendication 1, selon 
35 lequel le message d f application (MAP) construit 
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contient un descripteur (DAP) de 1 1 application (AP) 
avec au moins un identif icateur (IAPC) de la deuxieme 
partie d 1 application (APC), et le moyen gestionnaire 
(GIA) analyse le descripteur (DAP) dans le message 
5 d' application (MAP) re<?u par le terminal (2) afin que 
la deuxieme partie d' application (APC) soit extraite 
du message cj. r application (MAP) en fonction de 
1* identif icateur . (IAPC) dans le descripteur analyse 
(DAP) . 

10 

3 - Procede conforme a la revendication 1 ou 2, 
selon lequel le moyen de chargement (CAPC) est 
installe prealablement sous la forme d'un module 
logiciel dans le terminal (2) . 

15 

4 - Procede conforme a la revendication 1 ou 2, 
comprenant 1 1 introduction du moyen de chargement 
(CAPC) sous la forme d ! un script (SC) au cours de la 
construction (S4) du message d 1 application (MAP) a 

20 transmettre depuis le serveur (1) au terminal (2) et 
1 ' installation (T2) du moyen de chargement (CAPC) par 
extraction du script (SC) dans le message 
d f application (MAP) regu par le terminal avant le 
chargement (T4-T5-T6) de la deuxieme partie 

25 d' application (APC). 

5 - Procede conforme £ la revendication 1 ou 2, 
comprenant 1 1 introduction d'une adresse d'un script 
(SC) de chargement (CAPC) au cours de la construction 

30 (S4) du message d' application (MAP) £ transmettre 
depuis le serveur (1) au terminal (2) et 
1 1 installation (T2) du moyen de chargement (CAPC) par 
extraction de l 1 adresse de script dans le message 
d' application (MAP) regu par le terminal et un 

35 tel^chargement du script depuis 1 1 adresse extraite 
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dans le terminal avant le chargement (T4-T5-T6) de la 
deuxi&ne partie d 1 application (APC). 

6 - Procede conforme k l'une quelconque des 
5 revendications 1 & 5, coraprenant apres I'etape de 
charger (T5-T6) la deuxieme partie d 1 application 
(APC), un effacement (T7) de la deuxieme partie 
d' application dans le terminal (2) . 

10 7 - Proc§d6 conforme a l'une quelconque des 

revendications 1 A 6, comprenant apres 1 ' etape de 
charger (T5-T6) la deuxieme partie d 1 application 
(APC) , une transmission (T8) d'un message 
d' acquittement (ACK) depuis le terminal (2) au 

15 serveur (1) des que le moyen gestionnaire (GIA) a 
termini le chargement de la deuxieme partie 
d' application (APC) dans la carte a puce (3) . 

8 - Proc6de conforme & l'une quelconque des 
20 revendications 1 i 7, selon lequel la deuxieme partie 

d 1 application (APC) est segmentfee en des unites de 
protocole (EV1-EVN) qui sont conformes au protocole 
. -de communication et qui sont chargees successivement 
dans la carte a puce (3) sous la commande du moyen de 
25 chargement (CAPC) , la carte a puce transmettant une 
rdponse d T acquittement (REPn) apr&s le chargement 
(T5) de chaque unit6 de protocole (EVn) . 

9 - Proc6d6 conforme & l'une quelconque des 
30 revendications 1 a 8, selon lequel les premiere et 

deuxieme parties d' application (APT, APC) sont 
ecrites en des langages de haut niveau et sont 
converties en un langage ■interm6diaire interpretable 
respectivement par des moyens d' execution virtuels 
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(JVMT, JVMC) respectivement implement's dans le 
terminal (2) et la carte a puce (3) . 

10 -r Procede conforme a l'une quelconque des 
revendications 1 k 9, selon lequel le terminal (2) 
est un terminal radiotelephonique mobile. 
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